Add the "dist" directory to the .gitignore

[vincent-zurczak]

The build result should not be part of the repository. Given its name, I guess it is what dist aims at. There are other solutions to share JS applications.

I recently worked on Swagger UI, and they had chosen the same solution. By removing the "dist" directory from the history, my fork's size dropped from 60 Mb to about 6 Mb.

[Romathonat]

Indeed, I tought about it. The problem is that the /dist folder contains the bundle.js, wich is the minified version of the JS part of the application and wich is needed when deploying on heroku.

If I had a vps or a classic server to deploy, i could just generate the bundle.js when on the server, but with heroku I can't do that. Moreover the size of this file is something like 0.25 Mb for the production and ~1Mb for development, so it should not be a big issue. I you see a better way to do it let me know, tough.

In fact the really big-sized part of this project is the /semantic-ui folder, which is the css framework. There is a compilation step with it, that is why I need to include it directly instead of just letting the user download it as a dependency.

[vincent-zurczak]

0.25 Mb x N = many Mb :smiling_imp:

You could automate minification and the build proces with tools, such as Gulp. Then, uploading the distribution can be done with a script file by the CI (Travis here). If the project aims at being hosted by OW2, then you can ask them for a server. Otherwise, binaries could be hosted by Bintray.

You can also attach binaries to Github releases. In that case, you do not need anything else. Snapshot builds do not need to be available, only releases. It is the best and most simple solution IMO.

[Romathonat]

I assume you meant many Mb because of the versioning of git ? I don't have CI on this project yet (shame on me) because of the time I had to develop it, I prioritized functionalities. I am not sure if the project aims at being hosted by OW2, I'll ask @mdutoo . I will use github releases in the future, thank you for these pieces of information :)

[mdutoo]

Vincent, thank you for these good guidelines. We'll indeed try to follow them in the longer term.

Now, let me explain: Romain did that in the spirit of the "release early, release often" Open Source motto, so that we could have feedback before he left. ... On another side, I guess that you making this comment means that you've tried OCCInterface out ? In this case, thank you very much, and we now count you amount our users, therefore we all the more have to follow your advice :)

And we'd be very much interested in other feedback from you, especially on the functional side !

[vincent-zurczak]

I guess that you making this comment means that you've tried OCCInterface out

I have tried to compile it for test purpose, indeed. But I met errors due to different versions of NPM and NodeJS. I'll give it a try later. In the meantime, I wanted to highlight this issue about the dist directory.

... the spirit of the "release early, release often" Open Source motto...

And this is great IMO. :wink: There is nothing conflictual between this spirit and this issue. I would even say this is the exact opposite, it is better to take the right habits from the beginning.

• Have a minimal application that works.
• Have a reliable build mechanism.
• Host releases, as discussed, on Github.

Having an early version is the right opportunity to setup and experiment a build and hosting policy.

[vincent-zurczak]

Anyway, this is was a suggestion and a general notice. It does not hurry up. :)

[Romathonat]

Of course ! Do not forget that you can try it online (http://occinterface.herokuapp.com/), even if the only server avalaible (for the moment) does not contains occi-infra.xml (yet)

[Romathonat]

Done ! I removed the /dist folder and added travis CI to the project. Now each time someone push onto the master branch, travis build the bundle.js and deploy to heroku. Pretty clean I think !

[vincent-zurczak]

Great. :+1:

Pretty clean I think!

One question: why is there a file called ".gitignoreTravis"?

I also think there are too many information in the .travis.yml file. There is an e-mail that allows to identify a Heroku account, as well as an encrypted key. I would rather suggest to remove comments with sensitive data and rely on an environment varibale to inject the API key. With Travis CI, you can define such an environment variable for your repository. It is safer. The best option then would be to amend your last commit and git push force on the repo, so that this information remains confidential.

[vincent-zurczak]

Why is there a file called ".gitignoreTravis"?

OK, I got it.

[Romathonat]

(I answer for other people, eventually, I saw you got it) .gitignoreTravis is here to switch the .gitignore when building on travis. It removes the /dist of .gitignore in order to add it to git, so that we can correctly push to heroku.

Moreover don't worry about what you see, it is already the hash of the key to access to heroku. I used travis-encrypt : it encrypts the API key of heroku, and add the name and organisation of the current repo, so that this ecrypted key can only be used to push on heroku from this repo (no one can steal it). It is the way of doing it, in the travis doc.

What did you mean by :

There is an e-mail that allows to identify a Heroku account

?

[Romathonat]

I mean yes i put it there so that we remember the owner of the project on heroku, it could be a sensitive data so I should put it elsewhere. But where?

[vincent-zurczak]

You could just give a first name (and not a full name or an e-mail address). :wink:

[Romathonat]

Alright

[mdutoo]

@vincent-zurczak : for your npm & node build problems => try nvm, it is perfect to manage several versions concurrently ! or maybe do global (-g) installs