Hallo,
does there exist a way to install a specific version of a forge app from the marketplace? Currently I think it is only possible to install the latest version.
I would like to have this option for debugging purposes and to easily reproduce problems of customer who are still using an old version of our app.
Thanks,
Tim
This would really be a useful feature
Hey @TimZemlin, note that we have shipped a new forge build command allowing app developers to decouple app bundling and upload from deployment. You can keep old builds by deploying them to any environment and come back to them should you need to test, debug or reproduce issues.
That looks interesting. Would it be possible to also have a build created when one just used forge deploy.
Additionally, would it be possible to access old deployments that happened for example a year ago?
Nevertheless, thank you for the feature. Even if it does not help for deployments in the past, it will be useful for the future.
Best,
Tim
Tried the new forge build command and hit a blocker: Error: Manifest environment variables are not supported for builds.
Since our standard deploys now use env variables it is weird that build cannot? Is this getting fixed soon?
Chris
Hi @TimZemlin,
Would it be possible to also have a build created when one just used
forge deploy.
We aimed to ensure that the new commands maintain backward compatibility, preventing any disruptions for partners who have established their deployment workflows. As a result, the existing forge deploy command continues to function as it did previously. If you have been using forge deploy, you can also utilise forge build. The most recent build will be retained indefinitely, while older builds will be preserved for a minimum of 30 days.
Can you please elaborate on your need to be able to create a build with forge deploy?
Additionally, would it be possible to access old deployments that happened for example a year ago?
I’m afraid not, but you can access any build created today one year from now, provided that it is deployed to an environment. Hope this helps.
Cheers,
Angelina
Hi @Chris_at_DigitalRose,
the primary reason this implementation has not yet occurred is due to environment variables being environment specific whilst builds are not. Additionally, since builds can be promoted across different environments, there is a risk that an app developer might inadvertently promote a build with dev or staging variables to the prod.
Could you please provide more details on how this issue is impacting you?
Thank you in advance.
Cheers,
Angelina
Thanks for getting back to me @AngelinaIgnatova . We are using Forge Remote (migrating from Connect), and that requires us to use the env variables to change the manifest for the remote endpoints (default and regional) depending on deploy to dev, staging or prod.
Does the Forge team have a suggestion on how to deploy builds to the appropriate environment if the manifest has to change, but the build won’t build with env variables in it?
Appreciate any guidance
Chris
Thanks for the answers. It’s already helpful for us.
Does there exists any documentation for how long the builds are preserved. Also 30 days feels a bit short for me. It would be great if at least builds that were once used in a production deployment would be preserved indefinitely or at least for years.
This would help us achieve our goal of testing older production deployments easily.
Also it would be helpful to get the scheduled deletion date of the build when running forge build list. It would also be helpful to show to which environment this build is currently deployed and as which version. Another idea would be to also show this in Developer console .
Hey @TimZemlin,
Thanks for the feedback–glad to hear that the feature is already helpful for you.
At present, there is no set expiry date on builds as this is an area we are seeking feedback from developers on. This is partly why there is no expiry date shown in build list at the moment. We are trying to determine the most helpful determinant for persisting builds for long term storage. Your recommendation to persist production-deployed builds is actually an interesting idea-we’ll take that into consideration. Other strategies we are considering include allowing devs to “mark” builds for persistence.
Am I correct in assuming your need to test older production builds stems for need to maintain a number of old major versions due to installers not upgrading to the latest version?
We have plans to add build visibility to the dev console as well–will follow up here with updates.
Cheers,
Dylan
Thanks for the feedback. Improving the flexibility of forge build by enabling the use of manifest variables is certainly something we are looking into. In the interim, the way around this admittedly would be to create multiple builds at the same time but with some identifier in the tag to signify which environment the build is for.
Understandably, this doesn’t allow you to promote the exact, identical build across environments, but does at least allow you to ensure that the same source code is being used.
We’ll keep you updated regarding enabling manifest variables.
Cheers,
Dylan
Thank you for the response. This sounds promising. I am looking forward to the future development.
And yes, one of the main reason for our desire to keep old production builds is from customers not updating to the latest major version.
Best,
Tim
Hello everyone,
Is there a way to install a specific build (made with forge build) using installation link?
My Forge application integrates with our other product, which has multiple versions. As a result, the integration needs to communicate with different versions of our product. It would be ideal if I could generate a separate installation link for each build version.
Best regards,
Mark