Rebuild environment

[DuaelFr]

When you use the httpaccess function for example, a message informs you that you need to rebuild the environment by pushing new commits. Would it be possible to have a command to trigger a rebuild without pushing new code?

Thanks.

[pjcdawkins]

Possible, yes - with some drawbacks:

• it would involve making a new (empty) Git commit, so it would interfere with your repository history
• it would need #198
• we already have a platform build command so the naming will be tricky

[DuaelFr]

Isn't it possible to just run the script run on push using the last commit id as parameter? I don't think it is a good idea to add alter the git history using a platform-cli command because users would'nt understand why acting on the remote environment force the m to make a git pull on their local repository... That issue might need something new on the server side.

[pjcdawkins]

I don't understand this - "Isn't it possible to just run the script run on push using the last commit id as parameter?"

If there is going to be something new in the Platform.sh API, then it would also involve a Git commit. The principle is that the builds should be tracked in Git.

[DuaelFr]

The problem is that if you cannot set that parameter on the server without creating a new commit to trigger the build process, you have to make that commit relevant. So, you should include these parameters in a versionned config file.

I dislike the fact to make a dumb or empty commit just to trigger the build process and I suppose I am not the only one that dislike seing strange thing in his git log...

(Sorry for all that misunderstanding, it's probably due to my poor english skills ;) )

[pjcdawkins]

You are right - and if Platform implements this, I guess it's going to be incrementing a number in a config file somewhere. Unfortunately I think the CLI needs to wait until that's available in the API (no timeline yet), otherwise we'll end up with two different ways to do the same thing. I suspect the CLI at least would be able to 'git pull' (perhaps with --rebase) automatically after triggering a rebuild.

[DuaelFr]

Is there somewhere to report this issue on the API side?

[pjcdawkins]

I will make sure we have it tracked internally.

(you can report other Platform.sh issues by creating a ticket at https://marketplace.commerceguys.com/platform/support/create)

[peteward]

+1 for this feature.

I have been getting the following error which means I need a dummy commit to retry the build:

E: Error building the project: Resources exceeding plan limit; cpu: 1.15 > 0.96

This is just one example, there were other errors or problems that I've had where I needed a dummy commit.

[pjcdawkins]

Just to provide a bit more clarity: the principle reason for the "commit to rebuild" workflow is that the same files must always produce the same build. If your committed files did not change, Platform.sh will re-use a previous build.

We are planning ways to reduce the pain of this. For now, it's not really a CLI issue, but I'll keep this open for visibility.

[peteward]

Yes this is probably the wrong place to post this, I just thought it worth adding my experience of it.

[pjcdawkins]

And you were right, thanks - it's always worthwhile to get feedback!

[acrollet]

I'd like to add what I think is a valid use case for being able to trigger a build without having a new commit in the platform repository, which is for applications based on another distro. (As in https://platform.sh/2015/07/28/work-with-distribution/) In this case, one can make a commit to an upstream repo that the platform instance knows nothing about directly.

[pjcdawkins]

We do want to make this easier, and we have plans. But I will still riposte: if you want to manage the 'child' instance predictably and safely, it must contain a reference to a commit hash or version number of the distro.

[acrollet]

Purely for the sake of argument :)

Part of the advantage of using an upstream distro would seem to be being able to push out updates to multiple instances without having to generate many identical commits. The point about predictability is well taken though...

[JorisVanEijden]

So when I change a variable in the web UI I also have to create an empty commit and push it in order for the change to be available to the application?

[pjcdawkins]

@jorisvaneijden yes, for now at least. The web UI is just another interface for the same features

[SecondeJK]

+1 for command to rebuild. Checkout current head, rebuild - really need this for minor environment changes without empty commits that will make repo history messy

[pjcdawkins]

@SecondeJK environments now automatically rebuild whenever you change a variable, so there is a workaround available:

platform vset _redeploy "$(date)"

[stefandoorn]

@pjcdawkins That only trigger a redeploy for me, not a full rebuild.

[pjcdawkins]

Yes, the commit => build connection is still very much in place. I'm not sure why a rebuild would be needed without a change in source code, unless the build process contains inconsistencies?

(but redeployment doesn't need a fake variable anymore - there is a plain platform redeploy)

[stefandoorn]

My use case today was to find out on staging whether New Relic already is updated to work with PHP 7.3. No code change, just needed a rebuild to find out New Relic package is not updated yet after the maintenance rollout.

[pjcdawkins]

Platform.sh container updates for security/maintenance are applied on redeploy, without the need for a rebuild of the application code.

If it's an application-level dependency, then ideally the update should be in Git, in a lock file or similar.